Store credentials in Secrets Manager consistently + configurable KMS key - #5
Merged
Merged
Conversation
…figurable Add an optional secret_kms_key_id parameter (Terraform variable, service attribute, and UI-exposed field in the service spec) so each aurora-postgres-server instance can use its own customer-managed KMS key to encrypt its master password secret. Left unset, the secret keeps using the default aws/secretsmanager managed key, same as before. This is unrelated to aws_kms_key.aurora, the existing customer-managed key used for cluster storage encryption (AVD-AWS-0079) — that key stays as-is. Ports the same change already applied to rds-postgres-server in nullplatform/services-postgresql-rds. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Previously the app user's credentials generated by db_setup lived only in the Terraform state and as a plain nullplatform service/link attribute — unlike aurora-postgres-server, which stores its master password in Secrets Manager. Add an aws_secretsmanager_secret/_version pair (nullplatform/aurora/<service_id>/app) alongside the existing postgresql_role, following the same naming convention as the master secret, and expose its ARN as app_secret_arn on both the service and link attributes. Wire the new region variable and aws provider into db_setup (needed to create the secret), destroy the secret alongside the app user/password on service delete, and widen the aurora-postgres-db IAM policy from read-only GetSecretValue to full secret lifecycle management, scoped to the same nullplatform/aurora/* prefix. Ports the same fix already applied to rds-postgres-db in nullplatform/services-postgresql-rds. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
…ed key Trivy AVD-AWS-0098 flagged aws_secretsmanager_secret.app as explicitly using the default key: with no kms_key_id, the app-level PostgreSQL credentials are encrypted with the AWS-managed aws/secretsmanager key, whose policy cannot be audited, restricted, or revoked by us. Add a secret_kms_key_id variable (default null) and wire it through build_db_setup_context, mirroring the change already applied to the master secret in aurora-postgres-server. The value is inherited from the auto-discovered server's secret_kms_key_id attribute rather than exposed as a new per-database field, so a cluster's master secret and all of its app secrets share one key and one revocation point — the encryption key is an infrastructure-level choice that belongs on the server. Left unset there, the app secret keeps using the managed key, same as before. Also grant kms:Decrypt/kms:DescribeKey/kms:GenerateDataKey on the AssumeRole policy, scoped by kms:ViaService to Secrets Manager. Secrets Manager calls KMS on the role's behalf to wrap and unwrap the secret, so without it a customer-managed key fails at CreateSecret with AccessDenied on the key rather than on the secret. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
dfe1806 added the secret_kms_key_id parameter but not the IAM permissions it needs, so setting it fails at apply: Secrets Manager calls KMS on the role's behalf to wrap and unwrap the master secret, and the AssumeRole policy had no kms:* actions at all. The parameter has therefore been unusable since it shipped. Grant kms:Decrypt/kms:DescribeKey/kms:GenerateDataKey. The key ARN is operator-supplied and not knowable in requirements/, so Resource stays "*" and the grant is constrained by kms:ViaService instead — the role can use the key only for calls arriving through Secrets Manager, never to decrypt anything else with it. Same statement as the one now in aurora-postgres-db/specs/requirements/aws. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
db_setupare now also stored in Secrets Manager (nullplatform/aurora/<service_id>/app), matching howaurora-postgres-serveralready handles the master password. Previously they only lived in Terraform state and as a plain nullplatform service/link attribute. The new secret is destroyed alongside the app user on service delete, and its ARN is exposed asapp_secret_arnon service/link attributes. Theaurora-postgres-dbIAM policy is widened from read-onlyGetSecretValueto full secret lifecycle management, scoped to the samenullplatform/aurora/*prefix.secret_kms_key_idparameter (Terraform variable + UI-exposed field) so each instance can use its own customer-managed KMS key to encrypt its master secret. Left unset, it keeps using the defaultaws/secretsmanagermanaged key. Unrelated toaws_kms_key.aurora, the existing customer-managed key used for cluster storage encryption.Ports the same pair of changes already made in
nullplatform/services-postgresql-rds(see nullplatform/services-postgresql-rds#8) to the Aurora variant of these services.Test plan
terraform fmt/validatepass onaurora-postgres-server/deploymentandaurora-postgres-db/db_setup(done locally)aurora-postgres-serverrequirements/deployment in a test account, confirmsecret_kms_key_idleft empty still creates the secret with the default AWS-managed keysecret_kms_key_idto a customer-managed key ARN, confirm the master secret is encrypted with itaurora-postgres-dbservice end-to-end, confirmaws_secretsmanager_secretnullplatform/aurora/<service_id>/appis created with the correct credentialsapp_secret_arnshows up in service and link attributes🤖 Generated with Claude Code